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ABSTRACT 

Typically, the design and implementation of a conven- 
tional database system begins with the choice of a data 
model, the specification of a model-based data language, and 
the design and implementation of a database system which 
controls and executes the transactions written in the data 
language. For example, we have the hierarchical model, the 
DL/I language and the IMS System. By using an unconven- 
tional approach to the design and implementation of a basic 
database system, we can design a system to support multiple 
data models and several model-based languages as if the sys- 
tem is a heterogeneous collection of database systems. 

In this thesis we present a methodology for supporting 
hierarchical database management on an attribute-based data- 
base system. Specifically, we construct an interface which 
translates Data Language/One (DL/I) calls into attribute- 
based data language (ABDL) requests. We descibe the data 
Strucvures., the control structures, and the funetioms 


required to implement this interface. 
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iyolcally, the design and implementation Of a 
conventional database system begins with the choice of a 
data model, the specification of a model-based data 
language, and the design and implementation of a database 
system which controls and executes the transactions written 
in the data language. Thus, we have the relational model, 
the SQL language and the SQL/Data System. Similarly, we 
have the hierarchical model, the DL/I language and the IMS 
system. We may also give an example in the case of the 
CODASYL model, language and system. The conventional 
approach to the design and implementation of a system is 
limited to a single data model, a specific data language and 
a homogeneous database system. By using an unconventional 
approach to the design and implementation of a basic 
database system, we can design a system to Support multiple 
data models and several model-based languages as if the 
system is a heterogeneous collection of database systems. 

This unconventional design and implementation approach 
reveals two important database concepts. First, there is an 
exceedingly simple and powerful data model such that many 
other data models may be realized easily by this data model. 
This is the attribute-based model. Second, the attribute- 


based database operations - being high-level and primary 


operations, are such that most of the other model-based 


language constructs can be mapped into this set of primary 


operations on a straightforward fashion. Furthermore, the 
system which implements these primary operations is 
relatively small in size and executable either in ae single 
backend or in multiple backends. With these concepts, one 
can now use the attribute-based system to support many 
model-based interfaces. There could be an SQL interface so 
that the transactions written in SQL can be carried out. 
The execution Oe the transactions requires the SQL 
constructs to be transformed into the primary operations sie 
the attribute-based system through the interface. 
Similarly, there could be a DL/I interface so that the 
transactions written in DL/I can also be executed. In tnis 
way, the multiple interfaces allow the system to support 
multiple data models and data languages as if it is a 
heterogeneous collection of database systems. 

The attribute-based system supports the attribute-based 
data model, originally described in [Ref. 1] and extended in 
[Ref. 2]. Access to the attribute-based system is provided 
using the attribute-based data language Known as ABDL. ABDL 
is a high-level data language which supports the primary 
database and aggregate operations, INSERT, DELETE, UPDATE, 
RETRIEVE, MIN, MAX, SUM, COUNT Seand esc: There are two 
distinct features in an attribute-based system. First, the 


system is easy to implement because the model and its 
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Sper atitons are Simple. Second, the directory information is 
well defined and easily structured in the model. 

The attribute-based system supplies all the primary and 
aggregate operations required ina database system. With 
the specifications for another data language, we can 
construct an interface on top of the attribute-based system. 
imeoractice, we can construct a number of interfaces. to 
support relational, hierarchical, and network operations 
With a minimal effort. Such an approach is clearly = an 
attractive alternative to the approach where separate, 
stand-alone systems must be developed for specific models. 

The procedure to construct a relational, hierarchical, 
or network interface is done at both the database and data 
language levels. At the database level, the series of 
papers [Ref. 3], (Ref. 4], and [Ref. 5] demonstrated that a 
relational, hierarchical, or network database can be 
converted into an attribute-based database. At the data 
language level, we focus on the development of language 
interfaces to the attribute-based system consistent with the 
user's chosen language. At this level, we address’ two 
issues. The first issue is to determine how the operations 
of the chosen language can be implemented using the 
Operations of the attribute-based system. The second issue 
is the translation of the language of the interface to the 
attribute-based data language and the decisions regarding 


the interface mechanism. Although no implementation details 
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are rendered, algorithms are provided to aid in the eventual 
implementation of the primitive mappings. 

In this thesis, we investigate the design of a 
hierarchical interface for the multi-backend database system 
(MDBS). MDBS is an attribute-based database system, which 
is auto-configurable to either a single backend or to 
multiple backends. We are extending the work of [Ref. 5], 
which contains an initial design of a DL/I interface. In 
Chapter 2, the attribute-based model and hierarchical model 
are discussed. Also included in this chapter is an overview 
of the MDBS and the ABDI, and of TMseand Dina In Chapter 
3, we illustrate a methodology for mapping a hierarchical 
database into an attribute-based database. In Chapter an 
the data structures used by the interface to translate DL/I 
calls to ABDL requests are examined. Chapter 5 shows’ the 
mappings of the DL/I calls to the cepmemugueet a Al thougna 
no implementation details are rendered, algorithms are 
provided to aid in the eventual implementation of the 
primitive mappings. In Chapter 6, we present interface 
implementation considerations, and a brief synopsis of 
additional considerations to reach the goal of a functional 
interface. And finally, in Chapter 7 we conclude the 


thesis. 


ie 


Men On oeN Or THE DATA MODELS 


mee ere ee a eS UE SSCS 


metcmnourour intent) to describe in detail the data 
models of interest here, namely, the attribute-based data 
model and the hierarchical data model. Therefore, we only 
offer a brief overview of the pertinent aspects of these 


models. 


meee tHE ATTRIBUTE-BASED DATA MODEL 

In this section we introduce the attribute-based data 
model. A conceptual view of the model is offered as well as 
a discussion of the data manipulation language tnat is 
associated with it. Finally, a system which is implemented 
upon the basis of the attribute~based model and language is 
@iscussed. 

1. A Conceptual.View 

The attribute-based data model was originally 

described in ERG ieee. 1) It is a basic model which 
incorporates a few simple concepts. As its name implies, it 
1s built around the term attribute. Attributes and their 
associated values are represented by attribute-value pairs. 
An attribute-value pair is a member of the Cartesian product 
of the attribute name and the domain of values of the 
aieeribute. These pairs serve to represent all logical 


concepts within the attribute-based model. An attribute- 


Ue 


value pair is otherwise known as a Keyword. Keywords serve 
to form records, which are concatenations of keywords 
further concatenated with the record=-body. Possibly empty, 
which is utilized for textual information. (the record oaay 
is a string of characters which is utilized for textuem 
information. An example of a which is utilized for textual 
information .gerecord ijseas follows. 

(<TYPE , COURSED , <COURSE# ,CS3112>,<TIILE , Operating Sy¥ secu 

{Operating Systems principles and techniques} ) 
The angle brackets, <,>, enclose a keyword where the 
attribute and its value are separated by a comma. The curly 
brackets, {,}, enclose the record body. The entire record 
is enclosed with a pair of parentheses. 

To access the database, we employ predicates. A 
keyword predicate, or simply predicate, is a triple of the 
form Cattribute, relational yoperaven. value). Combining 
keyword predicates in disjunctive normal form characterizes 
a query of the database. When the attribute of a ke ywormeama 
a record is identical to the attribute in a predicate and 
the relation specified by the relational operator of the 
predicate holds between the value of the attribute and the 
value in the predicate, the keyword, and therefore the 
record, is said to satisfy the predicate. The query of two 


predicates 
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Guage. Teme weh eae (COURSE = CS4112) 


Will be satisfied by all records of the teacher file whose 
teachers teach the course numbered CS4112. 
2. The Multi-Backend Database System (MDBS) 

The attribute-based model is implemented in-= an 
experimental database system called the multi-backend 
database system (MDBS). MDBS cannot be classified as either 
a distributed or mnondistributed database system. One 
minicomputer functions as the controller, with multiple 
minicomputers and their disks configured in a parallel 
manner to serve as backends [Ref. 6], (Ref. 7], CRef. 8], 
[Ref. 9], and [Ref. 10]. The database is distributed on the 
secondary storage across all of the backends. User access 
is accomplished through a host computer communicating with 
mer controller. fhe MDBS structure can be classified as a 
centralized system. 

As shown in Figure 1, the controller and _ the 
backends are connected by a broadcast bus. When a 
transaction is received from the host computer, the 
controller broadcasts the transaction to all the backends at 
the same time. Each backend has a number of dedicated disk 
drives. Since the data is distributed across the backends, 
a transaction can be executed by all backends in parallel. 


Each backend maintains a queue of transactions. When one 


1D 


transaction has been executed, the backend can begin 
execution on another transaction from its queue. 

MDBS is implemented in several permanent processes. 
The process structure within the controller and each backend 
is shown in Figure 2. In addition to the processes “listeae 
the controller and each backend have GET and PUT processes, 
which are used in the broadcast and reception of messages, 
respectively. 

The controller is composed of three processes, 
Request Preparation, Insert Information Generation, and Post 
Processing. Request Preparation receives, parses and 
formats a request (transaction) before sending the formated 
request (transaction) to the Directory Management process in 
each backend. Insert Information Generation 1s uUsSeaiie 
provide additional information to the backends when an 
insert request is received. Since the data is distribu 
the insert only occurs at one of the backends. Thus ~ Giiges 
process must determine the backend at which the insert will 
occur, along with the cluster and descriptor ids for See 
Insert. Post Processing is used to collect all the resuiiee 
from a request (transaction) and forward the information 
back to the host computer. 

Each backend is also composed of three processes, 
Direectony Management, Concurrency Control, and Record 
Processing. Directory Management performs three functions, 


Descriptor Search, Cluster Search, and Address Generaruane 


iS 
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THE COMiROLLER 
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INSERT 
INFORMATION 
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CONTROL 


RECORD DIRECTOR: 
PROCESSING MANAGEMENT 


A BACKEND 





Figure 2. The Process Structure in the Controller 
and the Backends. 
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Descriptor Search determines the descriptor ids that are 
needed for a request. Cluster Search finds the cluster ids. 
Address Generation determines the secondary storage 
addresses necesSary to process the request. Concurrency 
Control determines when the request can be executed. Record 


Processing performs the operation specified by the request. 


3. The Attribute-Based Data Language (ABDL) 

The Attribute-Based Data Language (ABDL) is designed 
to perform the primary database operations, INSERT, DELETE, 
UPDATE, and RETRIEVE. Through the host a user issues either 
a request or ae transaction. A request iS ae primary 
operation along with a qualification. A qualification is 
used to specify the information of the database that is to 
be accessed by the request. It is defined in the next 
paragraph. A transaction is a list of two or more requests 
that are executed in a sequential order. There are four 
types of requests, corresponding to the four. primary 
database operations. 

Records are selected for retrieval by concatenating 
eeeqauery witn a target-list and a BY-clause. A target-list 
is a list of elements. An element is either an attribute, 
e.g., Grade, or an aggregate operator to be performed on an 
attribute, e.g., AVG(Grade). ABDL supports five aggregate 
Operators - AVG,SUM, COUNT,MAX, and MIN. The clause in the 


BY-clause 18S an attribute. The BY-clause is used to sort 


ih? 


according to the values of the attribute. Records are 
inserted into the database by attribute-value pair. Records 
are deleted from the database by means of a query. Finally, 
records are updated by juxtaposing a query with a modifier. 
The query specifies which records of the database are to be 
changed and the modifier specifies how the records being 


changed are to be updated. 


Be. ¢ THE HLER AO Gt CAD eee eile 

In this section we introduce the hierarchical data 
Moco le. We first offer a conceptual view of the model. 
Then, we discuss a database management system which 
incorporates the ideas inherent in the hierarchical model. 
And finally, we discuss a data manipulation language with 
which the database management system is implemented. 

1. A Coneeptual View 

Hierarchies are a natural way to model a myriad of 

real-world applications. For example, businesses, baseball 
teams, political parties, and our elected representatives, 
all have units of information which can be organized using a 
hierarchical  struictime. The hierarchical structure ies 
specified using hierarchical relationships, which represent 
a measure of precedence between units of information. Units 
of information, or data, are represented in a hierarchical 
model by entities. Entities have properties, called 


attributes, which uniquely identify each entity in an entity 


Sobeeeeoan entity set is Simply a grouping of all similar 
ec ities. The relationships between entities can be 
represented by a graph called a data structure diagram (see 
Figure 3). In this diagram all entity and attribute 
relationships are one to many [Ref. 11]. These one to many 
relationships have a certain direction which is depicted by 
the directed arcs in the diagram. Each directed arc points 
from the one to the many relationship. For example, between 
record types COURSE and OFFERING, the are representing the 
Memavionship PLANNED FOR points from COURSE to OFFERING, 
Since each course may have many offerings, but each offering 


is for only one course. 


cell) ise ae 


[a --+ 


COURSES NEEDED 


+------ —+ +----- Wo -+ 
| PREREQ } | OFFERING | 
+—-------- + wa 2------- + 
TAUGHT BY + 
Le ATTENDED BY 

+e eee + eee ay 

' TEACHER | He OBE NIT an 

terse e---- + teereere---- + 


Figure 3. A Data Structure Diagram. 


For the hierarchical model, the data structure 
diagram takes the form of a tree in which the direction of 
the arcs points away from the root. This tree has- the 


restriction that there can be at most one are between any 


Ze) 


two record types and is called .a hierarchical definition 
tree (see Figure 4). The hierarchical definition tree 
specifies both what record types are allowed to be included 
in the database and the permissible relationships between 
record types. In this tree, the level of a record type aie 
the measure of its distance from the root of the tree. The 
root record type is the highest level record type in the 
tree which, by convention, is referred to as level one. The 
other record types, called dependent record types, are at 
lower levels in the tree, i.e., at levels 2,3,4, and so on. 
Ancestor and dependent record occurrences can be identified 


by traversing the appropriate hierarchical path, which is 


Simply a sequence of records in which the records, starting 
at the root record, follow alternately in a ancestor- 
dependent relationship. Referring to Figure 3, if Wee 


desired to find which teacher taught a Math course offered 
in Monterey, the hierarchical path would be from the COURSE 
record occurrence, to the OFFERING record occurrence, and 


then to the TEACHER record occurrence. 


' COURSE 
—_—, of Sse F 
' PREREQ 1 | OFFERING} 
an > 
SS acss a _\ ee i. 
| TEACHER | aCe. 
+o eee ------ + +— ee —------ + 


Figure 4. <A Hierarchical Definition Tree. 


A characteristic of the hierarchical conceptual 
model is that there can be a varying number of occurrences 
of each record type at each level. However, each record 
occurrence (except for the root record occurrence) must be 
connected to an occurrence of an ancestor record type. 
Because of this, each new record to be inserted (except for 
a root record occurrence) has to. be connected to..-an 
Meeurrence of a parent type record. Deletions are also 
affected by this property. When a record occurrence is 
deleted, all of its descendent record occurrences are also 
deleted. 

Records are retrieved according to a selection = and 
qualification process. The qualification process expresses 


the selection criteria. A typical qualification takes the 


Porm: 


<data item name><conditional operator><value> 
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connected by Boolean operators AND, OR, and NOT. The 
conditional operators are relational operators <2) <-, > ae 
=o el iiGlang Ga OUuait heat1 on ars performed along the 
hierarchical path of the selected record. 

2. The Information Management System (IMS) 

The Information Management System (IMS) is a product 
of International Business Machines (IBM) Corporation [Ref. 
le], URef. 133 *anemeke ts) care It uses the hierarchical 
data model. The smallest unit of logical data is called a 
field (data item). A segment type (record type) is a named 
collection. Sof Sirelas. Occurrences of segment types are 


called segments (records). An example of an IMS database is 


shown in Figure 5. 


COURSE 





PV COURSE: Sette lee (*DATE {| LOCATION ; FORMAT | 





i*EMP# ; NAME | 1*EMP# | NAME | GRADE | 


Figure 5. The Logical Data Structure 
of an IMS Database. 
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3. Data Language/One (DL/I) 

The data manipulation language that IMS uses. to 
respond to queries of this database is called Data 
Language/One (DL/I). Users issue calls using DL/I to access 
the database. The DL/I calls are used to traverse the 
database tree. DL/I performs a preorder tree traversal. 
This means that the traversal begins at the root record and 
then proceeds through the tree going in top-to-bottom, 
left-to-right order. Thus, in our previous example the 
hierarchical path IMS would take would be from COURSE, to 
fegeeeo), tO OFFERING, to TEACHER, and finally to STUDENT. 

DL/I is designed to perform the primary database 
Siperacvions, GET, INSERT (CISRT), DELETE (DLET) and REPLACE 
(REPL). DL/I is invoked through procedure calls’ from 
applications programs written in PL/I, COBOL or Assembler 
Language. There are three types of calls, corresponding to 
the four primary database operations. Segments are selected 
meer etrieval Dy means of one or more qualifications. DE i 
Qualifies segments by specifying a segment search argument 


"7 ). The form of the SSA is: 
<SEGMENT NAMED><COMMAND CODE><QUALIFICATION> 


The SEGMENT NAME is the name of a segment type in the 
M@berarchical definition tree i.e., COURSE, OFFERING STUDENT, 
eeee ine QUALIFICATION 1S optional in the SSA and takes’ the 


form described above, with a minor exception. The only 


2D 


Boolean operators allowed are AND and OR. The COMMAND CODE 
1s also optional and delineates the various options of the 
call. Some of the more important options are: 
- retrieval or insertion of Semenworueoll cr 
the segments from the root to a specified 


segment type in a single DL/I call; 


- backing up to the first child under a seg- 
ment at any level; 


- retrieval of the last occurrence of a seg- 
ment that meets all specified conditions 
under a parent; 
- setting of the parentage to a specific seg- 
ment. 
Segments are inserted into the database by segment search 
argument. SSAS are used to locate the position in the 
database tree in which the segment is to be inserted. 
Segments are deleted and modified in DL/I only after being 
retrieved. A DELETE call deletes a segment and all of its 


descendent segments from the database. A “REPLACE ‘caqimt 


updates segments in the database. 
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meee MAPPING HIERARCHICAL DATA TO ATTRIBUTE=BASED DATA 


mmm rem rm 


Using a procedure originally outlined in [Ref. 5], we 
can map our sample hierarchical database into its ABDL 
counterpart. However, before doing so we must introduce and 
explain two notions whose existence are necessary to conduct 
the data conversion. These notions are that of the IMS 
eurrent MOct elon aideaeiat won. Tne — interface. “symbolic 


identifier. 


meee Hie NOTION OF CURRENT POSITION 

IMS uses a pre-ordered traversal to navigate a database 
tree. Quite understandably, this traversal need not begin 
at the root each time a call is made to the database. The 
traversal could easily begin at a child segment. Indeed, 
the segment requested could be a twin of the segment just 
previously retrieved. Thepetore, Mit 1S important to know 
the path of the traversal when conducting DL/I data 
manipulation operations. aes iS accomplished by 
designating the segment upon which the traversal has stopped 
mamecne current position. The current position of the IMS 
database is established after each retrieval or insertion 
operation. For a retrieval operation the current position is 
the segment just retrieved; for an insertion operation, the 


current position is the segment just inserted. 


B. THE NOTION OF INTERFACE SY MECET CawEy tenia 

In IMS it iS necessary to indicate order among twin 
segments. This is achieved by designating a sequence field 
in the segment. AS we convert our hierarchical data to 
attribute-based data, we also must be able to distinguish 
order among twin segments. Thus, in the conversion proecea., 
we shall assign a symbolic identifier to each record. The 
symbolic identifier of a record R is a group of fields 
CONS 1s tuane “Of 

1) the symbolic identifier of the parent of R; 


and 
2) the sequence field of R. 


C.4f MHE sCONVERSIONSOPSTHEMMS SEGMETiCS 
With the inclusion of the above notions, the database 
translation may now occur. An ABDL record may be created 
from an IMS segment using the following three step process: 
Step 1: For each field in the segment, form 
a keyword using the field name as the 


attribute and the field value as the 
value. 


Step 2: Form a keyword of the form <TYPE, 
SEGTYPE> where TYPE is a literal and 
SEGTYPE is the IMS segment type in 
consideration. 
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Step 3: For each sequence field in the symbo- 
PPe Identiti temmotsehne segment, form a 
keyword using the sequence field name 
as the attribute and the field value 
as the value. 


As an intermediary step it is helpful to utilize the 


above procedure to create attribute templates of the IMS 


database. Figure 6 illustrates these templates. These 
templates point out the attributes to be used in 
momstcruction of the ABDL record and demonstrate the 


formation of the symbolic identifier, which in each template 
has been underlined. The final product of conversion is 


shown as Figure 7. 


ao 


TYPE = COURSE 


| I 
| | 
'*COURSE# = 
i= Teepe 
| DESCRIPN 
$e eee eee eee + 
$e ee ee eee ee ee ee + ie a eee ee + 
' TYPE = PREREQ | | TYPE = Op tenia 
1 *COURSE# = '*COURSE# = 
'¥PREREQ.COURSE# = | '¥DATE = 
i TET eee | EOC A Mion 
$ owe weno aaseecees== + i SORMA Te = | 
hme me me ee nee ee eee + 
$e eee ee ee ee - + $ee ewe ee ee em ee eee -+ 
' TYPE = TEACHER | ' TYPE = STUDENT 
1 *COURSE# = '*COURSE# = 
|*DATE = | * DATE = 
1* TEACHER. EMP# = | '*STUDENT.EMP# = 
| NAME = | NAME = 
$o--------------- + i onaDE. = 
he ee a a a ee ee ee + 


(the symbolic identifier is marked with an asterisk) 


Figure 6. The attribute templates of MDBS records 
for the segments of Figure 5. 
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Reet ot?, <COURSEH 7 (OF COURSE> ,<TITLE,COURSE NAME> 
<DESCRIPN, DESCRIPTION>) 


See eee COURSE a On COURSE>, <PREREQ.COURSE?#, 
ion _PREREQ>, rig eke eee COURSE NAME>) 


col eee Oh PERING> )< COURSE? 7) OF COURSE>,<DATE,WHEND, 
<LOCATION, LOCN>, <FORMAT FORM) 


See eeee TEACHERS (COURSE ji OF COURSED ,<DATE,WHEND, 
<TEACHER.EMP#, ~TEACHER#>, <NAME,TEA NAME>) 


SiGe STUDENT AG OURSE? .¢ OR MCOURSE>, <DATESWHEN?, 


<STUDENT.EMP#,STUDENT#> , <NAME,STU_ NAMED, 
<GRADE, STU GRADE>) 


Figure 7. The Attribute-Based Representation of the 
Academic Database. 


Su 


IV. DATA STRUCTURES NEGESSAR iO es see se iy eee 


To effectively translate DL/I calls to ABDL requests the 
interface needs data structures to represent three tables 
and a series of buffers. These tables are the Status 
Information Table (SIT), the Hierarchy Table (HT) (see [Ref. 
5]), and the Organization Table (OT). Each buffer inva 
series of buffers will be called an Interface Buffer (IB), 
or simply buffer. It should be noted that these are 
maintained for each user. That is, each user has his own 


set of tables and buffers. 


A. THE STATUS INFORMATION TABLE AND THE HIGRARCHY Taber 

The SIT and the HT are created in order to keep track of 
the current position of the database. These tables have as 
many entries as there are interface buffers. They are 
dynamic tables instantiated upon the first call to the 
database. Thereafter, they are updated in accordance with 
the various DL/I calls. 

Each entry in the SIT .seonsisis or four fields: 
Seg(ment), Count, <Addr(ess), “and Guat tercarionm The 


meaning of the i-th entry in the SIT is as follows: 
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Sibr. see (i): the name of the segment type of 
the i-th level of the hierarch- 


Leal path: 

SIT.Count(i): the number of segments in the 
i-th buffer; 

Semericiair( 1.) the address of the segment with- 
in the i-th buffer; 

Sil. Qual (1): the SSA of the segment. 


Each entry in the HT consists of two fields: Field) and 


V(alue). The meaning of the i-th entry of HT is as follows: 


me (i): the sequence field name of the 
CurrEenu DOsturon ae level 1; 
mov (1): the sequence field value of the 


Current position at level i. 


pee 1GE ORGANIZATION TABLE 
The OT outlines the hierarchical structure of the entire 
database. This table lists all segment names contained in 
the database and stores the relationships among’ these 
segments. Kine hOue teeny NCwembLemarehicalea relavionships of the 
database are fathered in the database translation, the 
complete descendent information is not available to the 
Mmaerface. When carrying out the translation of a DL/I 
‘DELETE, the ABDL system will need to know the names of all 
of the descendents of the segment identified for deletion. 
mae OT provides this information. 
Actual implementation of the OT can take several forms. 
However, we are suggesting that it be a list structure. A 
linear linked list will facilitate representation of a 


general tree and allow traversal of the OT, to extract the 
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requisite descendent information. Each mode in the list wines 
five fields: Child, Seg, Symvib chop eye aid ss)> hone eee 


meaning of the i-th entry in the OT is as follows: 


Of Sen Gi: the name of the segment type; 
Oe S Vien) the symbolic identifier of 
the segment; 
OF. SEORED Ci: the sequence field of the 
segment; 

Oi.eCihi Vaem): the pointer to the left-most 
child at level i+1; 

OL. Si bine the pointer to the segment's 
Slbling at level i. 


Figure 8 illustrates the OT for our sample database. 
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A List Representation of the OT. 


Figure 8. 
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C.. THE INTERPACHBBUR eS Ek 

The IB 1S Simply a storage “area ~uvilized Sy Wea 
interface to store information needed to execute the 
translated DL/I calls. Although the exact role each buffer 
will play will be explained in the mapping of the DL/I 
calls, we can now say that a buffer is created for each 
operation which requires a retrieval. Upon a successful 
retrieval, all segment occurrences satisfying the query will 
be maintained in the buffer. This information will then be 


used for subsequent query execution. 
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(ere Namen, beCAtbLo LOeABDL REQUESTS 


We have demonstrated how hierarchical databases can be 
mapped into attribute-based databases. In this chapter we 
examine how calls in a hierarchical language, DL/I, can be 
mapped into the requests of the attribute-based data 


language, ABDL. 


fee THE DL/I GET CALLS 

The DL/I calls have been described earlier in = our 
overview Gn, 20G/ 1. Fach of these calls involves’ the 
retrieval of segment occurrences and, as such, are grouped 
together to be mapped to the ABDL RETRIEVE request. 
However, because each call Is quite different in 
functionality, each must have an individual mapping to the 
meDC RETRIEVE. 

1. Mapping the DL/I Get Unique (GU) 


to the ABDL RETRIEVE 


The general form of the DL/I GU is: 
GU Segment Search Argument(s) 
The general form of the ABDL RETRIEVE is: 


RETRIEVE Query Target-list [BY Attribute] 


ST, 


In order to successfully map the Gi) Co Gime RETRIEV2 3) Cee 
necessary to create an interface buffer (I8) as described 
earlier, which is used to store information retrieved from 
the database. The IB will be the mechanism through which 
movement up and down the hierarchical path is accomplished. 
Thus, at any one time it is likel-y Chat there wikia 
multiple instances of the VB The implementation, 
management, and placement of the IBs is discussed in Chapter 
ae 

To perform the mapping, the interface will Sf eeee 
substitute the ABDL reserved word RETRIEVE for the DL/TI 
reserved word -GU. Next, the interface takes the segment 
search argument (SSA) at level 1 and translates it into the 
ADBL query. This is a natural translation, since jeacm 
segment occurrence is mapped into the ABDL database as a 
collection of keywords. Placing a relational operator 
between the attribute and value of these keywords results in 
a predicate, and a query is merely a collection ou 
predicates. The final step in the mapping is the 
translation of the symbolic identifier into the target-—list® 
Again, this is a natural translation since both the symbolic 
identifier and the target-list are collections OF 
attributes. Having arrived at the end of the mapping, we 
can now explain the sequence of actions that will occur. 

Basically, a DL/I GU call will result in a series of 


ABDL RETRIEVE operations; one RETRIEVE for each SSA in the 
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GU call. An example utilizing our sample database will help 
to illustrate the mechanics of the mapping where _ the 
requirement is as follows: 

Get the first STUDENT occurrence who made an A _ in 


CS4900 at Monterey. 
ieee DL/I call is: 


cu COURSE CLEILE = UCsSiggo* ) 
OFFERING (LOCATION = 'MONTEREY') 
SU Dime T CCRADES=. Uh ™) 


The interface would respond to this call by performing the 


moelowing actions: 


step i: The first RETRIEVE would be formed as such: 


Pyne Vb d TYPE = COURSE) & (TETLE = CSH900) ) 
CCOURSE? ) 
The operation would result in having all COURSE# segments 
mectsfying the query ((TYPE = COURSE) & (TITLE = CS4900)) 
Placed into a buffer and sorted according to the values of 
their sequence field (see [Ref. 15]), which in this case is 
COURSE# (see Figure 9). The interface would then take the 


—_ 


first segment in the buffer and form the call in step 2? 


Sy 


CGOURe ui 12 
<COURSE#2> 


<COURSE#n> 


Figure 9. The COURSE/S Iameut 1: 


RETRIEVE ((TYPE = OFFERING) & (COURSE# = COURSE1) & 
(LOCATION = MONTEREY) 
(DATE) 
As one can see, the RETRIEVE request is formed using the 
second SSA and the sequence field name and value. The 
sequence field names of the two segment occurrences serve as 
links along the hierarchical path. This action will Sri 
all record occurrences satisfying the above query into a 
subsequent buffer (we shall call this buffer Buf2 and the 
aforementioned buffer Buf1). Again these records will be 
sorted according to the values of their sequence field, 


i.e., the attribute DATE (see Figure 10). 
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<DATE1> 
DATE 2 2 


<DATEm> 


Poouiee (Osemerne DATES in abut c. 


We must mention here that if there are no records” returned 
Memebui2 bdy the call, control is transferred back to step 1 
where the next record in Buf1t will be retrieved using the 
Operation called GET NEXT BUFREC(BUF#). This operation will 
move the pointer to the next record in the buffer. Upon 
completion of this operation, the action will proceed again 
womstep 2. 

Assuming that we have ae record in  Bufe, the 
interface shall again take the first record and form the 


call in step 3. 
Step 3: 


RETRIEVE (( TYPE = STUDENT) & (COURSE# = COURSE1) & 
( DATE = DATE1) & (GRADE = A)) 
( COURSE#, DATE,STUDENT.EMP#,NAME,GRADE) 


The RETRIEVE request is formed as in previous steps. 


meeewise, tme call will result im bringing all STUDENT 
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segment occurrences satisfying the query in ae subsequent 


buffer, Buf3 (see Figure 11). 
<COURSE, DATE | fe DiENm?: |) os URWAT ae 


! 

| 

| : 

<COURSEn, DATEnN ,STUDENT#n,STU_NAME, A> 
. 

! 

! 

| 


Figure 11. The STUDENT records in Buf3. 


Provided that segments were returned, these will be sorted 
by by their sequence field, i.e., by STUDENT.EMP#, and the 
first of these will be returned to the user. If no segments 
were retrieved, control will be returned to step 2 where the 
interface will choose the next record in Buf2. 

The action will continue until the RETRIEVE query is 
Satisfied or there are no more record occurrences in Buf1, 
at which time the user will be informed that the GU call was 
unsuccessful. The algorithm for the GU call is presented in 
Appendix A. 

2. Mapping the DL/I Get Next (GN) to the ABDL RETRIEVE 


The general form of the DL/I GN is: 
GN Segment Search Argument 
We map the Get Next to the ABDL RETRIEVE in a very similar 
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fashion as we have mapped the GU. Upon encountering a GN, 
miles interface will check the SIT for the current position of 
the database. This checking is performed because a DL/I GN 
retrieves the first occurrence of the specified segment 
following the current position. Thus, the interface must 
base upon this reference point to retrieve. Normally, a GN 
is preceded by a GU, Therefore, the segment we wish to 
retrieve is likely to be already available in the buffer 
mamen nolds the current position. If this is the case, then 
the interface needs merely to return the next segment in 
that buffer; no additional retrieval is necessary. Of 
course, if this is not the case, the interface will perform 
the necessary retrieval(s) and bring the required segment 
into a buffer. Upon completion of the request, the SIT and 
the HT must be updated, as each instance of aGN re- 
establishes the current position in the database. The 
algorithm for the translation is presented The following 
example illustrates the mapping: 

Retrieve the next segment who received an A in 
English. 


tne Diy i call wis: 


ele COURSE CT tithwee eGo lsh!) 
Os Ea NG 
SU DEN | CG RADE Seni.) 


Before proceeding, let us assume that the interface has just 


responded to the following DL/I call: 


a 


GU COURSE (TOLLE =SaCeE TSH 
OFFERING 


STUDENT (GRADE AS) 


Figures 12 through 15 represent the buffers that have been 
instantiated by the interface and the contents of the SIT. 


With this in mind, let us now proceed with the mapping. 


Pugure: Ve SEs lin, 


+ — = oP = om OF ow oo @ we @ @ @ @ we @ & &@ = + 
<DATE1> 
<DATE2> 
! <DATE3> 
i j 
j | 
1 
( i 
( 1 
| 1 
1 t 
1 1 
| 1 
J | 

-— eww wm mw mw ww ww ww ww ww ow ee + 


yy 


SGCUR SEY |, DATE Iss TUDENT#H1,STIU NAME,A> 


level Seg Count Oe Qual 
he we a ww a a a a wn a a a a a a a a a a a a a a a a a ee ee ee + 
1 7 COURSE 1 ok TATE = ee Gil Sas, 
m2 OFFERING 3 yyy 
ae: SUD ENT 1 ZZ Ze GRADE = A 
1 1 
: | 
I 1 
1 1 
I I 
i I 
I I 
i 1 
l 1 
wpe me me me mem ee a a a a a a a a a a a a a ee + 


Figure 15. The Status Information Table. 


The interface would respond to this call by 
Meriorming the following actions: 

Step 1: The interface will first compare the 
hierarchical path stated in the call with the database 
Em@eprency information held within the SIT. Referring to 
Figure 15 we can see that indeed the segment’ search 
arguments match the Seg(ment) and Qual(ification) fields at 
all three levels. Having established this, we can now 
proceed to step é. 

Step 2: On the basis of the GU call we know that 


moe. first record in Bufs is the current position of the 
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database. Utilizing this information, the interface Syaae 
check to see if there is a "next" segment in Buf3. If so, 
the interface will return the segment to the user in 
fulfillment of the request. However, in our example, there 
is no "next" segment. Therefore, the interface retracts one 
level and checks the contents of the corresponding buffer. 
The interface will determine if there is ae subsequent 
segment in Buf2. If not, the interface will retract another 
level, and will continue to retract, until the request 
either fails or is completed. In our case, there is a 
subsequent record in Buf2, <DATE2>. With <DATE2> the 
interface will form an ABDL RETRIEVE. This retrieévaiaee 
done “in Steppe a. 


Step 3: 


RETRIEVE (CTYPE = STUDENT ee (COURSE? =) COURSE mn. 
(DATE = DATE2) & (GRADE =e 
(COURSE#,DATE,STUDENT.EMP#,NAME,GRADE) 

Our request is satisfied as Figure 14. The first segment in 
this buffer is returned to the user. If there had been no 
segment returned, the interface would check Buf2 again for 
another subsequent segment. ek successful, another 
retrieval would be formed. If not, the interface would 
retract another level as described in step 2. 

3. Mapping the DL/I Get Next Within Parent (GNP) 


to the ABDL RETRIEVE 


The general form of the DL/I GNP is: 


46 


GNP Segment Search Argument(s) 


Mae Mapping Of the GNP to the ABDL RETRIEVE is identical to 
the mapping of the Get Next with one exception. When a GN® 
=o 1S issued, the interface will return a segment 
occurrence that is either a sibling of a segment that has 
been previously retrieved which matches the SSA of the 
current segment, or is the first segment satisfying an ABDL 
RETRIEVE request for SSAn where n is greater than i in the 
SIT and HT. This difference can be visualized if we revert 
to our example for the DL/I Get Next. In that example we 
retrieved the "next" STUDENT segment that received an A in 
English. We could have achieved the exact same results with 


the following DL/I call: 


oN ec OU RSE SuitLe wameeeNGlISE) 
OREERING 
SlUDENT (GRADE 


"A') 


However, for our GNP example, let us assume that the above 
call was made immediately after the GN call in the above 
example. Therefore, the situation is that the current 
segment is the segment in Buf3 (see Figure 14). Responding 
to the above call, the interface will proceed to check the 
existing buffers to see if the buffer information is useful. 
The interface will arrive in Buf3 and attempt to return the 
"next" segment occurrence in that buffer. However, Buf3 has 


Only one occurrence. Therefore, the interface will retract 
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to the next highest level ,Buf2, and check for subsequent 
segment occurrencese Since there is another segment 
occurrence in Buf2, i.e., <DAITE3>; an ABODE RETRIEY fe ee 
formed as follows: 

RETRIEVe Coty e STUDENT) & (COURSE? “= "OGURSE? 1) a. 


(DATE DATE3) & (GRADE = A)) 
(COURSE# ,DATE,STUDENT .EMP# , NAME ,GRADE) 


We shall assume that the request is satisfied. Therefore, 
the first Segment occurrence retrieved into our new Butsmeee 
returned to the user. Again, this iS identical to @ene 
action for the Get Next call and does not show the subtle 
difference between the GN and the GNP calls. If we modify 
Our example Slightly, the difference becomes apparent. Let 
uS assume that instead of the previously stated GNP call, 
the following Get Next Within Parent ecall occurred 


immediately after the aforementioned Get Unique call: 


GNP STUDENT (GRADE = 'A') 


Notice that we now have the identical situation as described 


earlier, i.e., the current position of the database is the 
first segment in Buf3. With this in mind, we can now 
illustrate the difference between the algorithms (see 


Appendix A for the algorithm GNP). 
Step 1: The interface first compares the segment 
search arguments (SSAs) of the GU call and the GNP call. 


The comparison is made by looping through the SIT entries, 
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BSinee the hierarchical path from the GU is stored in the 
SIT. While in most cases the GU call will provide the 
hierarchical path down to the level of retrieval (as it does 
here), there is no requirement for the GU to do so. As _ it 
memeaces to the GNP call, the main objective of the GU call 
momo eStablish the current position and to identify the 
"Darent™ segment. The "parent" segment for the GNP call is 
the lowest level SSA of the GU call. Since there may be any 
number of levels of the hierarchical path omitted from the 
mee ooh Of the GU call to the first SSA of the GNP call, 
the interface will need to discern this fact. If indeed 
there are missing SSAs, the interface must consult the OT in 
order to retrieve the appropriate segment occurrences into 
the buffers. iais ss “accomplasned: “in )=Sstep ~3 of the 
algorithm (see Appendix A). Returning to our example, we 
find that the last SSA of the GU matches the first SSA _ of 
mame GNP, i.e., STUDENT (GRADE = 'A't). The interface must 
now determine if there are any more SSAS in the GNP call. 
hatseis accomplished in step 2. 

SUcpme ald thes SCeo. tne w= Interface compares “the 
SSAs of the GNP with the entries on the SIT. The reason 
that this is necessary is the essential difference between 
the Get Next and the Get Next Within Parent. Since the 
function of the GNP is to retrieve only segment occurrences 
Within the parent, it is essential to know exactly who the 


parent is. As stated earlier, the "parent" is defined in 
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the GU call by the Silast  s4- The segment type to be 
returned is the last SSA of the GNP call. These of course 
could be the same. In our example they are. This fact 
would be recognized by the interface, and since we have a 
buffer already in existence for this level, the interface 
would attempt to return the next record in that buffer. 
However, for our example there is no "next" record. 
Therefore, the interface would return a ‘'failure' to the 
user instead of returning a STUDENT occurrence for a 
different OFFERING, which would have been the result of a 
Get Next call. Thus, the essential difference between the 
GN and the GNP is clear. The Get Next in this case would 
start retracting to find the "next" segment, whereas the Get 
Next Within’ Parents justraurtcsce 
4, Mapping the DL/I Get Hold Calls to the ABDL RETRIEVE 
Dina has three Get Hold calls: the Get Hold Unique 
(GHU), the Get Hold Next (GHN), and the Get Hold Next Within 
Parent (GHNP). <A Get Hold call is used in DL/I to retrieve 
into a work area and hold the record in that work area so 
that the record can be deleted or updated. ABDL does not 
have this requirement. Therefore, when the interface 
encounters a GHU call, a GHN call, or a GHNP call it will 
treat these calls as a GU call, a GN call, and a GNP call, 
respectively. With the exception of the "H", the general 
form of the Get Hold calls is identical to the forms ote 


non-hold counterparts. Therefore, the mappings described in 
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the previous three sections are applicable to the Get Hold 


calls. 


eter erNGe ar DL7/T LSRI TO THE ABDL INSERT 
ine penerdal form of the DL/I ISRT is: 
ISRT (Hierarchical Path SSAs] 
Unqualified Segment Type 
A brief reminder, the DL/I ISRT traces SSAs along the 
MmiLerarchical path in order to insert the unqualified segment 


type at a level we shall call n. 


The general form of the ABDL INSERT is: 
INSERT record 


hie = mapping of the DL/I ISRT to the ABDL INSERT is 


facilitated by DL/I's rules. These rules mandate that: 


1) With the exception of a root occurrence, 
the parent occurrence of the record to 
be inserted must already exist in the 
database; 


2) The ISRT call must specify the complete 
hierarchical path to this parent; 


3) The call must specify the type of the 
segment to be inserted. 
Vaid! Mon Lie tnt omtattoneprovided by the DL/I ISRT 
call, one might conclude that the ABDL mapping is simply a 
concatenation of transformed DL/I segments. However, for 


two reasons this is not the case. The first reason deals 


With the OT as “introduced vearl vere Although ancestor 
segment occurrences must already exist in the database, 
there 1s no such requirement for the segment type which is 
to be inserted. In order to perform its function, theme 
must have complete knowledge Or all parent-child 
relationships within the database. Thus, updating the OT is 
a required step for all insertions of new segment types; the 
second reason has to do with the current position. Recall 
that a DL/I ISRT call must establish the current posittrtoqman 
the database in order to utilize DL/I Get Next and Get Next 
Within Parent calls. Our naive insertion would not have, 
nor could not have, this capability. We shall now proceed 
with the mapping. 

To begin the mapping, the interface will wutitize (ee 
ISRT SSAS specified to form ABDL RETRIEVE requests to 
retrieve segment ancestors into IBs in the same manner as 
the GU was conducted. However, instead of returning a 
"failure" if no segment is retrieved at level n,_ the 
interface will merely update the Organization Table and 
perform the insertion. The interface prepares for the 
insertion by getting the field names’ and values of the 
segment to be inserted from the DL/I work area. It then 


forms an ABDL INSERT statement of the form 


INSERT (<Type,Sn>,<fl,¥ lo 65 <0 l= ly eatin cp eee aa 


»where Sn is the segment name, f is a field name, v is’ the 


ye 


corresponding field value, and k1 to km are keywords formed 
meom the DL/I qualifications for the segment to be inserted. 
With this request the mapping is complete (see Algorithm 
ISRT in Appendix B). The following example illustrates this 
mapping. 

Requirement: Add a new STUDENT occurrence for- the 
@eurse entitled CS4112. 

ine DL/I eall: 

ould new Segment in the 1/70 area) 

iSkt COURSE il Rie peteme CSHa 12") 

Orr ek i NG 

STUDENT 
The interface would respond to this call by performing the 
Following actions: 

Step 1: The interface will respond to this call by 
forming an ABDL RETRIEVE request with the first SSA of the 
oR . 

nee Peer = COURSE ce @lunibeke = CS4112) ) 
(COURSE#) 
This action will pull all COURSE# segments satisfying the 
request into Bufl in the order of their sequence field 
Mmeaaues. Ihe interface will then use the first of these _ to 


Benmm the retrieval in step 2. 
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Sepia. 


RETRIEVE (CTYPE = OFFERING) 4. (COUR SE ieee CGlh oc am 
(DATE) 
This action will pull all DATE segmentsS SatiSsf Yi1no See 
request into Buf2 in order of their sequence field values. 
As in step 2, the interface will use the first of these _ to 
form the retrieval in step 3. 

Step 3: Since this is the segment which 1S to wiee 
inserted the routine differs somewhat from the previous 
RETRIEVE requests, which were identical to those followed in 
carrying out the mapping for a GU. The request is of the 
following torn: 


REDRIEY Bet ve 
(DATE 


STUDENT) & (COURSE# = COURSE#1) & 
DAEEI (STUDENT. EMP# ) 


Although the syntax is identical to the previous’ requests 
and the result is the same, i.e., all STUDENT.EMP? segmenite 
satisfying the request are sorted and placed in Buf3, the 
intent of the request is different. The purpose of this 
request is to check to see if there are any twin segment 
occurrences to the segment occurrence that is to be 
inserted. If there are occurrences, then the buffer will be 


utilized for the insertion. If not, then the interface must 


update the OT. The INSERT request is formed in step 4. 
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Step 4: Prior to forming the ABDL INSERT request, the 
macertace will go to the DL/I I/70 work area in order to 
retrieve the field names and values of the segment type to 
be inserted. Assuming that the STUDENT segment’ to be 
inserted has EMP# = 49, NAME = Zeke, and GRADE = A, the ABDL 
INSERT request is as follows: 
Miomun (CTYPE, olUDENT>, “COURSE? , COURSE I>, 

<DATE ,DABEI>, <SPUDENT.EMP# ,49>, 

<NAME,ZEKE> ,<GRADE,A>) 
where the <COURSE#,COURSE#1> and <DATE,DATE1> represent 
fields and values of levels 1 and 2 respectively. With the 
successful completion of tnis request, the mapping comes’ to 


an end. 


eee ENG THE DL/I DELETE TO THE ABDL DELETE. 


The general form of the DL/I DELETE is: 


DLET segment occurrence 


The DLET call must be preceded by a GHU call, GHN call, or a 
GHNP call, which retrieves the segment occurrence and holds 
it in a work area so that the DLET can effectuate segment 
deletion. The general form of a DLET call will delete the 
specified segment occurrence and all of its children. The 
interface will use the OT to identify these segments for 


deletion. 


Do 


The general form of tne ABDL DERETE sceeqiesr 1s. 
DE WE eo Ue tay, 


To perform the mapping we must first have the interface 
translate the GHU, GHN, or GHNP into a GU, GN, or agi 
Once done, these commands will be translated as mentioned 
previously and the specified record occurrences will be held 
in the buffer. Next, the interface must make use of the OT 
in order to find all descendent segment occurrences of the 
segment earmarked for deletion. Having accomplished this, 
the mapping continues. The DL/I DLET will be translated 
into a number of ABDL DELETES. This number will be 
determined based on the ancestry of the segment to be 
deleted. The number will be high if the deletion is of a 
root occurrence and low if the deletion is of a child. The 
reserved word DLET will be translated into ABDL's DELETE. 
The query part of the ABDL delete will be constructed from 
the symbolic identifier of the segment marked for deletion 
conjuncted with each descendent segment name. 

As previously mentioned, these descendent segment names 
Will determine the number of DELETE operations necessary in 
order to fully implement the DL/I DLET task. Beginning with 
the segment identified in the GHU, GHN, or GHNP, the OT will 
be traversed. Descendent segments will be alternatively 
RETRIEVEd and DELETEd by the interface. The action will 


stop once all dependent segments are deleted. The algorithm 


mone tne DLET call is presented as Appendix C. Note that a 
temporary SIT and HT have been established. These are 
necessary because a DLET does not alter the current position 
of the database. However, in order to form the ABDL 
RETRIEVES and DELETES, the interface must read the SIT and 
HT. If we do not update the SIT and the HT, there will be 
no entries for any levels below the last level in the SIT 
mm@aeHl. = This, of course, will result in having segments 
left in the database that should have been deleted. On the 
other hand, if we update the SIT and the HT, we could re- 
establish the current position, which would be an unwanted 
side-effect. Therefore, we must have the temporary 
meructures. An example call using our sample database will 
help to illustrate this mapping. 

Delete the OFFERING occurrence for first Wine Tasting 
course offering in Monterey. The DL/I call: 

en COURSE CT Fae = SEW INE TASTING® 

OlEERING CEOCATEON = uMGNTEREY ") 
BEET 
The interface responds to this call by performing the 


following actions: 


Step 1: The interface considers the DL/I GHU call to be the 


same as the DL/I GU call. Having done so, the first ABDL 
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RETRIEVE ia2s81 ormede 


RETRIEVE (CTYPE = COURSE) SG CT 1T iie S=aeaee Eee oa is) eae 
( COURSE#) 


Step 2; AS with the GU, a second retrieval is formed wusaiee 
the first record in Buf? satisfying the request ain Step 18 
RETRIEVE (( TYPE = OFFERING) & (COURSE# = COURSE#1) 
& (LOCATION = MONTEREY) ) (DATE) 
The result of this step is to retrieve all satiSf ya 


records into Buf2 and to designate the first of these for 


deletion. Deletion for this segment is carried out in step 


o 
Swep 3: 


DEERE CC iene 
(DATE 


OFFERING) & (COURSE? = GGUS E par. 
DATE1) 


This request will complete the task of deleting the segment 
occurrence but will not suffice for completion of the DL/I 
DLET. To do so, the interface must delete all descendent 
segment occurrences. In order to accomplish this, ime 
interface enters the Organization Table with the pointer to 
the first child segment of the segment deleted in step 3. 
For our example let usS say that the descendent segment 
occurrences are comprised of one TEACHER segment occurrence 


and 10 twin STUDENT occurrences. These segments will be 
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alternately retrieved and deleted. The next two DELETES 
Mmebiustrace the retrieval and deletion for the first two 
dependent segments. Note the absence of the accompanying 
RETRIEVES. These requestS were not necessary, since we are 


at a leaf in the traversal sequence. 


Vee CClrie= TENCHER) £ (COURSE = COURSE#1) 
GD ARE s= Ade Ay)? 


oct eameC TYPE = STUDENT) Sm@eOURSE = COURSE#1) 
<Gn he eee Be) 
Upon completion of all of the deletions for the dependent 


segments the action will be completed entirely. 


Beeeeiar PING THE DL/I REPL CREPLACE) TO THE ABDL UPDATE 


The general form of the DL/I REPL call is as follows: 


ae 


meee the DL/I DLET call, the REPL call must be preceded by 
one of the Get Hold calls. The Get Hold call serves to 
retrieve the appropriate record into a work area so that the 
record may be modified. After the record is modified in the 
work area, the DL/I REPL call is issued which makes’ the 
modification permanent. 


The general form of the ABDL UPDATE request is 


UPDATE query modifier 


where the query specifies which records of the database are 


ae 


to be updated, and the modifier specifies how the records 
are to be changed. 

The mapping of the DL/I REPL call to the ABDL RETRIEVE 
proceeds initially with the interface translating the Get 
Hold call into the appropriate Get Sealig This actitenm 
retrieves the record to be modified. Recalling our earlier 
discussion in the ISRT translation, we can apply the same 
logic as to not by=-passing the translation of the Get Hold 
call in favor of the straightforward "one-step" translation, 
1.e€., we must establish the current position. Therefore, 
once the Get call is translated, the interface will use the 
symbolic identifier of the segment to be modified as the 
query portion of the ABDL UPDATE. For the final step in the 
mapping, the interface will retrieve the update information 
from the DL/I work area and use this for the modifier. The 
algorithm for the mapping is presented as Appendix D. The 
following example illustrates the mapping: 

Change the prerequisite of Course# 4 from Math to 
Discrete Math. 


The DL/I eall to accomplish” this sas tollowse 


GHU COURSE, “CCOURS Ease 

PREREQ 
change title to 'Disecrete Math' in I/O work area 
REEL 


The interface would respond to this call by treating the 


Get Hold Unique ecall as a Get Unique call. Steps 1 and 2 
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em@ewetie TOrmatvion Of the appropriate ABDL RETRIEVE calls. 


Svep. |; 


owe TYPR = COURSE) & (COURSE# 
(COURSE#) 


4) ) 


Step 2: 


BSTRIEVE ((TYPB = PREREQ)@c (GOURSE# 
CAR EREGR COURSE? ) 


4)) 


Recalling the actions involved in the RETRIEVE request, we 
know that the first segment in Buf2 is the segment to be 
modified. Therefore, the interface will form the query 
portion of the ABDL UPDATE as follows: 

Sere = PREREGwe& CCOURSE? = 4) & 

(PREREQ.COURSE# = COURSE#1) 
Upon accomplishing this, the interface will proceed to the 
DL/I work area in order to get the update information. With 
hes information, the modifier portion of the ABDL UPDATE 
memmest 15 formed, i.e., <STITLE = DISCRETE MATH>. The 
entire ABDL UPDATE call is formed by concatenating the 
"guery" portion of above to the modifier as follows: 

UPDATE OCRYPE = PRERE@) & CCOURSE# = 4) & 


(PRER ES; COURSE = COURSED 
Sethe SCRE T Ea rH? 


Upon execution of this request, the call is completed. 
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VI. IMPLEMENTATION CONCERNS SAND Dial eore ae 


INTERFACE CONSIDERATIONS 


In this chapter we present interface implementation 


coneerns, anda brief synopsis of additional considerations 
to reach the goal of a functional interface. Specifically, 
we shall discuss the location of the interiace; era 


combining of DL/I calls, and the implementation of DL/I 


segment search argument (SSA) command codes. 


A. TBE LOCATIONMOR THE chim hp Atta 

We have discussed the interface, thus far, in terms of 
functionality, without mention of the exact location vor saa 
interface within the overall database system. AS we see it, 
there are four location possibilities. These are: 1) 
placing the interface in a separate location, i.e., within 
its own processor; 2) placing the interface within the host 
processor; 3) placing the interface within the MDBS 
controller; and 4) placing the interface in one of the MDBS 
backends. Additionally, there is a fifth Option. Thats 
the interface can be distributed among one or more of the 
aforementioned locales. Or these DOSSID11i tues, we 
recommend the adoption of option 2, i.e., placing the 
interface within the host. We make this recommendation for 


several reasons. First of all, if one Sitwates sera 
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Mmanertace Within a Separate processor, or distributes it 
meme Dares Of the system, one compounds the interprocess 
communication problems of the system. Secondly, if one 
places the interface within the controller, one jeopardizes 
m@emcdoility Of the controller to perform its function, i.e., 
the controller would be in danger of being overloaded. 
Thirdly, if one places the interface within a backend, one 
undermines the intent of the MDBS system. The backends were 
specifically designed for data management functions only. 
And finally, it just makes sense to place the interface in 
the host. This is because the interface can make use of the 
resident database interface structures located within the 


host. 


Pee COMBINING DL/TI CALLS 

A preponderance of DL/I calls to the database can occur 
mo combination. For example, it is standard to see a Get 
Unique followed by a Get Next, and a Get Hold Unique 
followed by aDLET. Therefore, the interface must be able 
to distinguish among these calls, and place combinations of 
ems in the correct sequence. In order to accomplish this, 
it is incumbent upon the interface to be able to update the 


mayervidual user's SIT and HT throughout the user's session. 
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C. IMPLEMENTATION OF THE SEGMENT Soran ARGUMENT 

COMMAND CODES 

The SSA command codes were discussed in Chapter 2. As 
described earlier, these are special codes which allow 
variations touthewbasicasDL/ ieee a lise In... order to fui 
implement a functional interface, algorithms for these codes 
must be developed. In this section we discuss some of the 
details necessary for their eventual implementation. We 
shall limit our discussion to three command codes, D, F jijaga 
V, which are the most prevalent. For a discussion of the 
remaining codes (C,L,P,Q,U,N,-), see (Ref. 131] andjihewe 
14]. 

1. The Command Code D 

The command code D permits retrieval, update, or 

insertion of some or all of the segments from the root to a 
specified segment type in a single DL/I call. For example, 

GU SC OU haces” 

OFFERING (LOCATION = 'MONTEREY') 

will retrieve not only the segment satisfying the OFFERING 
SSA, but will also retrieve the COURSE parent segment. The 
interface must be able to recognize this. This should not 
be a difficult modification to the basie GU algorithm. dan 
example, there could be a conditional which would be 
activated upon recognizing “the ) in the woos Thass 


conditional would send the appropriate segment to the user. 
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pumilar modifications can also be made to the [SRT and REPL 
seeorithms. 

2. The Command Code F 

The command code F provides a means of stepping 

backwards under the current parent. This is important in 
Situations where it is desired to retrieve a sibling that 
precedes the current segment. For example, suppose we 
desired to retrieve the name of the teacher of Jones 
attending Course# 1 in Monterey. Without the command code 
mere 15 no way for us to do this, since TEACHER and STUDENT 
meee siblings. We could possibly form two DL/I GU calls, but 
each of these would return segments that, when placed 
together, would not necessarily satisfy the original call. 
With this command code we can form the DL/I calls as 
Pellows: 

PummcOouURSe (COURSE# = '1?) 

me ORRERING (LOCATION = *'MONTEREY’) 

foie st UDENT “NAME = 'JONES*) 

nie TEACHER “* F 
The interface must be able to recognize that the current 
parent is the OFFERING segment satisfying (LOCATION = 
"MONTEREY'), and must be able to backtrack in order. to 
retrieve the correct TEACHER segment. The modification to 
the GNP algorithm necessary is, that upon recognizing the 


command code F, the interface must consult the SIT and HT in 


oo 


order to locate the buffer holding the current position, and 
use the current position as the basis for retrieval. 
3. The Command Code V 

One uses the command code V in a very similar 
fashion as the Get Next Within Parent. The subtie 
difference can only be understood, however, by fitsw 
expanding our explanation of the notion of current position, 
As stated earlier, the current position is defined as_ the 
segment last accessed via a "get" or "insert" operation. 
However, this is not the entire story. Each segment along 
the hierarchical path to the current segment is considered 
as the current of that particular segment type. hot 
example, if the segment last retrieved is a TEACHER, then 
that TEACHER is the current segment, the TEACHER's parent is 
the current OFFERING, and the OFFERING'S parent isa 
current COURSE. Recall that aGNP retrieves segments only 
from the current parent (in our example, the OFFERING 
segment). By using the command code V, any ancestor can be 
designated as the "current parent", i.e., we can choose the 
COURSE segment instead of the OFFERING segment. Thus, the 
use of command code V_ directs IMS away from the current 
segment type named in the SSA to which it is appended in 
much the same fashion as the Get Next Within Parent. 

The command code V is used with a Get Next call. By 
proposing a more specific example than our earlier one, we 


can illustrate the use of the command code V. Suppose that 
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im 1S desired to get the next Teacher whose name is Smith. 


The code for our example would be as follows: 


GU TEACHER (NAME era) 
mae COURSE*V 
Ore nee 


TE AGHibeR ON AME sa" SM imu) 


Note that the use of the command code V does not require the 
presence of a preceding GU call in order to reposition the 
user to the start of the database. Tiakse wii Scauise no 
problem with either the algorithm GU or the algorithm GN 
Since we require a GN call _ to specify the entire 
hierarchical path. However, the GN algorithm must be 
modified in order to recognize the presence of the command 
code. Mie =anodililcarvione vow vwnemw= alcorithm focuses upon 
recognizing the V, at which point the GU algorithm will call 
the Get Next Within Parent algorithm, sending the SSA with 


the V appendage as a parameter. 


OW 


VII. RESULTS AND CONCENS ICs 


As stated earlier, by using an unconventional approach 
to the design and implementation of a basic database system, 
we can design the system to support multiple data models as 


if the system is a heterogeneous collection of database 


systems. Our unconventional approach is geared EO 
flexibility, efficiency, and extensibility, which makes it 
an attractive alternative to conventional approaches. By 


developing multiple data language interfaces we offer users 
the alternative of our unconventional approach without 
incurring any Wrercrarmnineg. cess. In adopting our system, 
users appear to have their same old database system, but one 
that works faster. 

In this thesis we have presented a methodology for 
SUpDpOrt ing hierarchical database management on an 
attribute-based database system. Specifically, we have 
constructed an interface which translates DL/I calls into 
ABDL requests, and which maintains appropriate buffer and 
table contents. We have described the additional data 
structures, control structures, and funeticns requared aia 
implement this interface. Finally, we have shown that DL/I 
calls can be mapped to ABDL requests in ae relatively 
Straightforward manner. Based upon this information, the 


hierarchical interface can be implemented. 
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Although the hierarchical interface can be implemented 
based upon the work we have presented, we must caution that 
this work has addressed only the hierarchical model. Two 
other interfaces must also be completed to correspond with 
the other two popular data models, i.e., the relational and 
metwork models. [Ref. 16] and (Ref. 17] have designed an 
interface for the relational model. However, the network 
interface is still yet to be developed. Given the fact that 
two of the three interfaces have been designed, it is 
possible that implementation can proceed in these areas. 
However, the implementor(s) must proceed with caution and 
must pay Daley euler attention to commonalities = and 
overlapping of functions between the two interfaces. It is 
one thing to strive ahead, and yet another to strive ahead 


Biindly. 


69 


APPENDIA A - THE GET BUCO is 


A, THE ALGORITHM GEPSUNTOUE GE) 


This-algorithm ‘executes theefol lowincee ea 


GU S171 Q1 
S2 Q2 


5n3@n 


where each Si iS a segment type at level i, each Qi is a 
qualification (possibly null) and n>=z 1. We assume that 
the sequence field name of segment type Si is Fi. The 
target list is defined as the sequence field up to level n- 
1. At level n, the target list is a list of all fields 


requested in the original DL/I call. 


Step 1: (Retrieve root segments into 
buffer and update SIT, HT) 
RETRIEVE ((€ TYPE = S1) & Q1) 
(target list) 
sort attribute Fl. Ourferpeaddtess fa. 
Count 7 
SEIT(1) <== 4siecoa cap 
let(F1,V1) be the sequence field 
of the segment in address a 
HTC1) <2e(e eve 


Site 02? (All segments retrieved?) 
i <== i + 1 
Lt “lone en 
go to step 6 
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Steps: 


Step 4: 


Seep -5 > 


Seep 6: 


(Retrieve segments at i-th level) 
Roe Ve mGqmeny Pawel) & (F1 = V1) 
OME ce ae 
Cech i=geeeVi-e1) & Q1) 
Guareetemians tc) 
SOGUpouUeepuco wuMmmsout fer address a, 
COUN eae 
if “G@ <> OP then 
go to step 5 


(Retract one level and try again) 
1 <-- i-!] 
Pf Pie sehen 


return ('failure'’, -) 
CSc, acehos G-—-ol) (i) 
ec <-- cH] 


tf ver 20 then 
go to step 4 


(update SIT,HT) 

SiG) eau ear Oi) 

let (Fi,Vi) be the sequence 
field of the segment 
in address a 

Gaon Cave) 


(Operation Successful) 


number of entries in SIT or HT <-- n 
current position of database <-- n 
parent position <-- n 

return ('success', buffer address a) 


The Algorithm GU. 
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B. THE ALGORITHM GET NEXT (GN) 
This algorithm executes the followers, ty came: 


GN S71 Q1 
S222 


Speen 


where each Si is a segment type in level i, each Qi is a 
qualification (possibly null) and mn >= 1. dn cheeckingiae 
see if at any time the SSA of the GN call precedes the 
corresponding SIT entry in the traversal sequence, we assume 
that the code for a segment name A is less than the code for 
a segment name B if A precedes B in the traversal sequence; 
mis the number of e6ntries. in ene) si leon ea. The target 
list is defined as the sequence field up to level n-1. At 
level n, the target list is a list of all fields requested 
in the original Or ivcalrik. 
Siteopt: (Find t such that. the condition 

(CSi =" Si t.segwene. 

(Qi = SIT.Qual (ig) eisesorest ned 

for 1 <= i) <Gagae 


butonoteutom 1 = (tel). 
t <-j- 0 


2 





Sleep 2: 


Seep 3: 


Step 4: 


Btep 5: 


Step 6: 


Beep {: 


(Compare the SIT with each SSA) 
tC <-- t+1 
iat > 1 Oru Mm then 
go to step 3 
(FL,Vt) <-- HT(t) 
Moe So: 7G Lise Cty) a 
(OG l==s1 i. Oud Ct om tnen 
go to step 2 


(Get rid of any unnecessary buffers) 
t <-- t-1 
Whi Leste <= made 

clear Buf(t) 


Giombur femal onan tous auseful 7) 
iter =O. tien 
go to step 10 


(Perhaps the necessary segment 
is in the buffer?) 
eS aeaee eb.) Sa seer e aes ) 
ieee os He Cen 
1 <== 1+7 
go to step 14 


(Hibilce sli iret norm armoneiseuset ul 7 
pe Ge a ieee Camas te =e Tm) ) 
itt, v= -m- tien 
i <-j- i+1 
go to step 12 


(S$(t+1) precedes SIT.Seg(t+1)) 
Poet t+) Col besser (biome t nen 
return ('failure', -) 


ie 


Sie peo. 


Seepea: 


Step 0s 


Sep “A 


SLED Ve. 


(S(t 1) Sdoeseact 

precede SIT.Seg(t+1)) 

if S(t+1) > SIT.Ses( t+ ieee 
i <=— t+1 
go to step 12 


(1 <2 t< m < neS(te) 2 ee ce eee 
Q(t+1) <> SIT. Qual Gee) 
1 <-- t+1 
RETRIEVE @@TYPE =9Si) 6.02 ea 
Scavege 
& (Fi=14= Vale eco) 
(target siice 
sort attribute Fi, buffer address a, 
COUnEme 
go to step 13 


(Retrieve root segments into buffer and 
update SIT,HT) 
RETRIEVE SC CTY P Bese S11) 2k) {Gee 
& Q1) 
(targereiisT> 
sort attribute Fl, buffer address a, 
COuln cose 
STT (1). <=2: 10S iimeeatonp 
HTC1) ==) (1a 


(All segments retrieved?) 
1 <== 14+1 
lf 2 2 neenren 

go to step 16 


(Retrieve segments at i-th level) 
RETRIEVE (CTYPE = Si) & (F1 = V1) 
cae 
& (Pie) = "Viel eee) 
(target list) 
sort attridute Fi, butler Wsedmess a. 
Coun Uae 
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Step 13: (Any segments retrieved?) 
piece. > 0 then 
go to step 15 


Step 14: (Retract one level and try again) 
i <-- i-] 
feo. = Ofseaen 
return ('failure',-) 
Game. sone cee 
ec <-- cH 
if © = 0) then 
go to step 14 


Step 15: (Update SIT,HT) 
SO Gao eee) 
let (Fi,Vi) be the sequence 
field of the segment 
ln address a 
4UT(Ci) <-- (Fi,Vi) 
Poe LO TStCep. 1) 


Step 16: (Operation successful) 


number of entries in SIT or HT <-- n 
current position of database <-- n 
parent position <-- n 


return('success',buffer address a) 


The Algorithm GN. 


es. 


C. THE ALGORITHM GET NEXT WITHIN PARENT (GNP) 


This algorithm executes the following DL/I call; 


GU 51 Q1 
See 
She ein 


GNP Sb Qb 


Se Qe 


where the Get Unique call is aS previously specified, each 
Sb through Se is a segment type in levels b through e, each 
Qb through Qe is a qualification (possibly null) in levels b 
through e, b >= e, and e >= 1. The target list is defined 
as the sequence field up to level n-l1. At level n,) tae 
target list is a list of all fields requested in the 


original DE/ I cai. 


Step 1: (Compare the SIT and Sb) 


t <-- 0 
Repeat 
t <={- t+1 
(FteVt) e<==05 Tce 
Cites 
CSD =" Oo) Paseo Cla 
(Qb ="Siieeus Cre 
OR (t > n) 
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Step 2: (Check to see if the first SSA 
of the GNP matches the SIT) 
ifn Sib Siiloes (ty me 
(Qb Silva lt top 
then go to step 3 
else if t > n then 
go to step 4 


Srep 3. ici bee Enen 
(Mere lsmmoretianmone SSA 
in the GNP) 
t <== b 
Poor: tC <=j$- t+1 
if “Gs-> emoreau m then 
go to Step 4 
(Ft,Vt) <-- HT(t) 
if (St =sSlteseg(t)) & 
Cores himeougqict)) then 
Compe m lOO r 
else ( b = e) 
ec <== cH 
ii “O1e=. Oe nen 
return ('failure',-) 
else 
gO) temo Lepats 


Step 4: (We must retrieve further along the 
hierarchical path without establishing 
the current position) 

TEMPSIT <-- SIT 
TEMPHT <-— HT 
1 <-- t-1 
While i <= e do 
RETRIEVE (CTYPE = Si) & (Fi = Vi) 
bP 
chat =a 1 ) 
Chance 1st) 
sort attribute Fi, buffer address a, 
COUllts-c 
ifsc = .0"tmen 
return ('failure',-) 
TEMPS 1 WC le Gesu oeceia 4 ) 
TEMPHT(i) <== (Fi,Vi) 
i <=-- i+1 
1 <-- e 
go to step 18 


‘al 


Step 


Step 


Step 


Step 


Step 


Step 


(Clear any unnecessary buffer) 
t <-- t-1 
While ste<= ede 

clear Buf(t) 


(No buffer informatucn womucerue) 
if -t sso tien 
go to step 12 


(Perhaps the necessary segment 
is in the buffer?) 

1 <s' Gy but 9s) ea cman) 

if C= "eAtaen 
i <=- i+1 
go to step 16 


(Entire buffer dnformatvonmes Uusenuse 
1 <= t and m <i, “Oeie see =r) 
if t=) mM then 
i <== i+1 
go to step 14 


(Check to see if the desired segment 
precedes the current position in 
the traversal sequence) 

if S(t+1) < SiivSeecrsiperiten 

return ('failure', -) 


if S(t+1) > SIT.Seg(t+1) then 
i <== t+ 
go to step 14 


ire 


See Oy ails 


svep 12: 


Svep 13: 


Step 14: 


Seep 15. 


(eG be on ote pe = So lT.Seg(t+1), 

ake 1) “<Ow Slt cual (rep 

1 <-- t+ 

Met RIEVE sOCIY SR SS ommec (PF 1] = V1) &... 
& (Fi-1 = Vi-1) & Qi) 
(target list) 

Sort AUCH DUUCEttmOlr rer aGdress di, 

count me 
SOmtGn Suess 


(Retrieve root segments into buffer 
and update SIT,HT) 
RECUR beer demeG Ur | = V1) 
& Q1) 
(target list) 
SOGu auUruDULeC mie mOULter address a, 
County 2c 
SIT(1) <-- (S1,¢,a,Q1) 
HT(1) <-- (F1,V1) 


(All segments retrieved?) 
i <== 141 
if i> e then 

go to step 18 


(Retrieve segments at i-th level) 
Poth Even DVipie— soi) gerd) = V1) 
Beira terse 
& (Fi-1 = Vi-1) & Qi) 
(target list) 
SOrt avtrloutemiiy, buiter address a, 
COU ae 


(Any segments retrieved?) 
ite 1G, <0? 0) tien 
2OuUO ssl epee 


i 


Steomio. 


Sue pelea 


SuepS ke. 


(Retract one level up to level b and 
try again) 
1 <-j- i-1 
if i = b-1 then 
return (€'fallupew ye» 
(Si co aed ) ee = cine 
ec <-- cH 
lf <C Vomercunen 
go to step 16 


(Update SIT,HT) 

SITCi) <-- (Si,c,a,Qi) 

let (Fi,Vi) be the sequence field 
of the segment in address a 

HT(i) <== (Fi. Vip 

go to. steps 


(Operation successful) 


number of entries in SIT or HT <-- e 
current position of database <-- e 
parent position <-- e 


return('success',buffer address a) 


The Algorithm GNP. 
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noe END eben oeomhAaM ISRT 


This algorithm executes the following DL/I call: 


where each Si 


qualification 


the sequence 
mareet list 
1. At level 


requested in 


oLep) 1: 


Is qual 1 Q1 
pe ae 
sn-1 Qn-1 
on 
1s a segment type in level i, each Qi is a 


(Mescibly nul merand=ne >= 1. We assume that 
field name of segment type Si is Fi. The 
is defined as the sequence field up to level n- 
Oeecne Carget listwisceeeces Jist of all fields 


the sorrveinal: Bil weal: 


(Retrieve root segments into Buf 
and update SIT,HT) 
1 <-- 1 
REDREEV Bee Cie Eas 1) & 61) 
(tarcetelist) 
SOrt avr Pomme ipmeourter address a, 
COUN tae 
it CO v=-0 eee Cnn lee nen 
return C'faiture .—) 
it (Ch =O ec men) et ier 
update OT 
ec <-- 1 
2O UCTORSLepe 
ST Gi “==. (Sierra Ot» 
let (F1,V1) be the sequence field 
of the segment in address a 
Har A) ae Geter) 
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Sep aee (All ancestor segments retrieved?) 
1 <=-—- i+1 
if i> (n-1) then 
go to step 6 


Steo s. (Retrieve segments at i-th level) 
RETROBVE. (@enYP EB = 957) ee Gel oma 
Sree 
& (Fis! = )Si— ieee) 
(target list) 
SOG, altribute Fi. burier addwesseae 
Coun te 
if e <> 0 then 
go to step 5 


Step 4: (Retract one level and try again) 
i <-- (i-1) 
if i= 0 then 
return ('failure',-) 
Gee Oi) <2e srr) 
ec <-- (c-1) 
if @.="0 tae 
go to step 4 


Step ess (Update SIT,HT) 
SIT(1) <== “(Si cana) 
let (Fi,Vi) be the sequence 
field of the 
segment in address a 
HT(i) <-- (Fi,Vi) 
go to step 2 


SCCpaoe (Check to see if there are 
any twin segments) 


RETRIEVE (CTY Phe =s Sco esc Gee ey | oe eee 


& (Fi-1 = Vi-1) 
(target list) 
if ec = 0- then 
update OT 
Qe <-- 1 


82 


SCep 7s 


Step 8: 


(Make the insertion) 
get field values of Sn from 
DE7 ie ayo work area 

INSERT (<TYPE,Sn>,<F1,V1>,..., 
Chie (: Viewer 
Gale ecm: ?) 

SiTCr) <=— (Si,¢.4,01) 

Hii aeaes (Beale 


(Operation successful) 

number "Of -entrves Bamsell or HT <-= n 
Current position of database <-- n 
parent position <-- n 

return ('success!, buffer address a) 


The Alcor tenmerskil. 
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APPENDIX C — TRE, REGO RI cae | 


This algorithm executes "the  fotmlowl nk, tere aree 


GHCUJCNICNP] 51) Osi 
S2 Q2 
Sn Qn 
DEEL 


where each Si is a segment type at level i, each Qi is a 


qualitveavien 


the sequence 
target list 
1. At level 


requested in 


Step 


(possibly null) andn >= 1. We assume that 
field name of segment type Si is Fi. The 
is defined as the sequence field up to level n- 
n, the target list is a list of all fields 


the sorieinalepe7 trea. 


Case Call = 
GHU : Tranistate Goines Gu 
GHN : Translate GHN into GN 
GHNP : Translate GHNP into GNP 


Execute the GU, GN, or GNP 
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Peopeenmmnaver the Oi with current segment.child) 


Wegep cl sc -seumronrmscaegment.child 
TEMPSIT <== osiT 

TEMERT <-- HT 

Procedure Pretrav (nodeptr) 


Q <-- nodeptr 
While q <> nil do 
Read node[q] 
Lt hdnpenl hd orca entl then 
heh Ege SEG NAME) ¢ 
Gras Vil) &... 
& (Fi-1 = Vi-1) & Qi) 
(target list) 
i <== i+17 
TEMES Gee cHew(S1,Cc,a,Qi) 
TEMPHT(i) <-- (Fi,Vi) 
DEBE? & (CCT Yebe=e 1) 2k 
CRs ey tos oi, 
& (Fi-1 = Vi-1) & Qi 
PReUravecehd iad 
Pretrav(sibling) 
end while 
end procedure Pretrav 


AeA 2 OP ae aml a 
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APPENDIX D - THE SEGOR Di eras 


This algorithm executes the tovliowmee epi lec au 


GHCUJCINIJCNP] > 1384 
ooo 
Se on 
REP 
where each $i 1s a segment type at level 1, each Qi is a 


qualification (possibly null) andn>= 1. We assume that 
the sequence field name of segment type Si is Fi. Aj iS~= an 
attribute of field J, whose value will replace the oldyy 2mm. 


Of Ul deldaxac 


Step 12 “Gaseneakiee- 
GHU : Translate GHU into GU 
GHN : Translate GHN into GN 
GHNP : Translate GHNP into GNP 
Execute the GU,GN, or GNP 


Step 23: = Crorm the “quem 
((TYPE = Si) & CEI S2ev cae. 
(Fi-1 = Vi-1) & Qi) 


Step 3: (Form the “modifier") 
go to I/O work area to get 
update information 
<Aj = Vj> 
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Step 4: (Perform the request) 
Were “OCR Phew ot) cee! = Vij) & .. 
(Fi-1 =i -eeeen) <Aj-= Vj> 


the Algoritom Rerie 
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